Library Application Security

Because a COM+ library application is hosted by another process, which may have its own security settings, security for library applications requires special consideration. The following constraints apply to library application security:

• Library applications run under the host process security token rather than under their own user identity. They have only as much privilege as the host has.
  
  
• Library applications do not control process-level security. No users in roles are added to the security descriptor for the process. The only way for a library application to perform its own access checks is to use component-level security.
  
  
• Library applications can be configured to either participate or not participate in host process authentication, by enabling or disabling authentication.
  
  
• Library applications cannot set an impersonation level; they use that of the host process.

Using Library Applications to Limit Application Privilege

In some cases, you may want to configure an application specifically as a library application so that it runs under the identity of the hosting process. Doing so fundamentally limits the application so that it can access only those resources that its client, the host process, can access. The threads that the library application components run on use the process token by default, and therefore when they make calls outside of the application or gain access to resources such as files guarded with a security descriptor, they appear to be the client. For applications that perform sensitive work, this may be an easy way to control the scope of their actions.

Enforcing Role Checks

A security factor to consider is whether or not the library application should use role-based security. If role-based security is used, you must be using component-level security for any access checks to be carried out. The roles assigned to the library application are not reflected in the process security descriptor. The only authorization that the library application can control is at the component level.

For more information about component-level security, see Security Levels for Access Checks.

For step-by-step instructions on setting component-level security, see Setting a Security Level for Access Checks.

Enabling or Disabling Authentication

Another decision to make is whether callers of the library application should be subject to the process-level security checks of the hosting process—that is, whether to enable or disable authentication.

For example, if the library application is to be hosted by a browser, it might need to receive unauthenticated callbacks. To address this need, you can disable authentication so that the hosting process does not perform security checks for callers of the library application. When you disable authentication, the library application effectively goes unauthenticated and all calls to it succeed. Callers of the library application are not subject to the security checks of the hosting process. Basically, the library application is tagged as unauthenticated, and security checks are omitted for calls to the library application.

For an overview of authentication in COM+, see Authentication in COM+.

For step-by-step instructions about how to enable or disable authentication in a COM+ library application, see Enabling Authentication for a Library Application.